Added the ability to specify options, or default arguments, for plugin invocations #899
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
This PR fills in a gap that is currently present when using the Package/Xcode Plugins to perform source code generation, either manually using the
RswiftGenerateResourcesCommand
, or automatically using theRswiftGeneratePublicResources
orRswiftGenerateInternalResources
plugins. The gap to which I speak is that if any customization is needed, i.e.rswift
arguments, that can only be done when manually running theRswiftGenerateResourcesCommand
plugin and the arguments must be specified each time the plugin is used.This is obviously not an ideal scenario, so this PR seeks to alleviate this issue by adding support for an "options" file. The way in which this works is slightly different for Xcode Plugins vs. SPM Plugins, but the premise and formatting is the same:
.rswiftoptions
file is declared in your sources root (Xcode Plugins can create an additional file in the root of the project as well)rswift
utility.The
.rswiftoptions
file is a JSON file that has a very simple schema:All of the fields in this JSON object are optional and are applied in a systemic and deterministic way when executing the plugins:
.rswiftoptions
file that is located in the same directory as the project file invoking the plugin. These options are combined with the options in the previous step in such a way to where the previous options will not be overridden by the new options, should a particular option already be set..rswiftoptions
file that is located in the root directory containing the source files for the given target. These options are combined with the options in the previous step in such a way to where the previous options will not be overridden by the new options, should a particular option already be set.When done in this manner, this allows for one to use these options files to specify the arguments that should always be provided, but allows for those values to be overridden if invoking the plugin directly.
How are these changes implemented?
The way in which the implementation is done is multifaceted:
RswiftShared
to contain code that should be shared between therswift
executable target as well as the plugin targets. TheAccessLevel
,BundleSource
, andResourceType
types were all moved into this new target.RswiftShared
sources directory. This is done to get around an issue where plugin targets cannot have a dependency on a library target so the sources are brought into each of the plugin targets via this symbolic link.Decodable
for easy parsing..rswiftoptions
files and combine these options with any provided from the plugin invocation, if relevant.Any testing done?
Yes, testing was performed locally using an Xcode project and a Swift Package, each of which was tested by using various combinations of the aforementioned plugins, options files, and options provided when manually invoking the
RswiftGenerateResourcesCommand
. All results of this testing align with the deterministic manner in which those options should have been applied, as described above